The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Traditionally, developing a business application involves including all of the logic of the application in one executable. The executable may include several components (e.g. executable files, dynamic-link library files, etc.), but when the executable is delivered all the components thereof co-exist all at the same place all at the same time. A new way of developing business applications is provided by the Service-Oriented Architecture (SOA) standards. With SOA, the development paradigm is changed so that different pieces of business logic are developed by independent providers. The SOA providers typically host services that provide the business logic on servers that are accessible over local networks and/or the Internet. For example, a SOA business application may comprise code written by in-house developers, where the code makes calls to services which provide the business logic and which are hosted by independent SOA providers that may be dispersed across the globe.
SOA standards address various issues such as, for example, code re-use and rapid development of business applications. But like any evolution in technology, along with SOA come some new challenges. One such challenge arises when SOA providers make changes to the services they provide. Because with SOA a business organization no longer owns all the code and relies on SOA providers for the logic of a business application, the business organization has no control of when or how a service executing at a server of a SOA provider is changed. Such change to a service may be benign from the perspective of the business organization; however, the fact that the service has changed is significant and the business organization utilizing the service needs to be aware of the change in order to evaluate the change and to avoid adverse consequences.
For example, suppose that a travel agency is using a business application that is receiving (sourcing), and displaying to end users, exchange rates information from a service provided over the web by a SOA provider. If the service providing the exchange rates information changes for whatever reasons (e.g. to improve exchange rate calculation algorithms), the actual change in the received exchange rates information is benign and insignificant; however, the fact that the service has changed is important because it may affect how the different portions of the business application interact with the service. In a well-governed application development environment, when a change in a service provided by a provider is made, the developers of business applications that utilize that service need to investigate and determine whether the change affects a particular business application or is indeed benign. For example, a change in a service may result in the service providing more information that may be of interest and that may add value to a particular business application. In another example, a change in the service may be such that it prevents the business application from interacting with the service any longer. Thus, the fact that a service has experienced changes is important, and such changes need to be detected and reported to the developers of business applications that access the service.
The problem caused by service changes is exacerbated for services that are not used very frequently by business applications because the information provided by the services is more obscure. For example, suppose that a travel agency business application is capable of displaying the timetable of bus schedules in Istanbul, Turkey, even though it is not likely that such timetable would be frequently accessed by application users in the U.S. When the service providing the timetable of bus schedules in Istanbul changes, it is necessary to proactively detect that change in order to be able to determine whether the change affects the travel agency business application in any way.
The problem caused by service changes may arise in a variety of operational scenarios. For example, some changes to services may be changes that totally disable the operation of a business application. In another example, it is possible that some changes to services are malicious, e.g. changes in the format of the data provided by a service may be intentionally designed to mislead. In yet another example, changes to a service may be versioned, and different executable versions of the service may evolve over time.
Based on the foregoing, there is a need for techniques that provide for detection and proactive notification of changes to services that are accessed by business applications.